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DETAILED ACTION 



Claims 1-31 of the preliminary amendment are pending in this application. 



Information Disclosure Statement 

The information disclosure statement (IDS) submitted on October 30 th , 
2001 is in compliance with the provisions of 37 CFR 1 .97. Accordingly, the 
information disclosure statement is being considered by the examiner. 



Specification 

The disclosure is objected to because of the following informalities: the 
phrase "because they require information the user does not have to make a 
request" is unclear (page 1 , paragraph 4, lines 4-5). Appropriate correction is 
required. 



Claim Objections 

Claims 13, 25 and 27 are objected to because of the following 
informalities; appropriate correction is required. 
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In referencing to claim 13, it is believed the phrase should have read 
"routing said response to said client interface device" (line 4). 

In referencing to claim 25, the phrase "remote loading function load 
functions that reside on devices logically connected to said module manager" 
(lines 4-5) is unclear. Should the phrase have read: remote loading function load 
information modules that reside on devices logically connected to said module 
manager. It is suggested applicant clarify. 

In referencing to claim 27, it is assumed that applicant is referring to 
remote information modules (line 1) and will be treated as such. It is suggested 
applicant clarify. 

Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

Claim 11 recites the limitation "said subscription center" (line 3). There is 
insufficient antecedent basis for this limitation in the claim. Should the claim 
have read: said subscription database? 
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Claim Rejections - 35 USC § 102 
The following is a quotation of the appropriate paragraphs of 35 

U.S.C. 102 that form the basis for the rejections under this section made in this 

Office action: 

A person shall be entitled to a patent unless - 



(e) the invention was described in (1) an application for patent, published under section 
122(b), by another filed in the United States before the invention by the applicant for patent or 
(2) a patent granted on an application for patent by another filed in the United States before 
the invention by the applicant for patent, except that an international application filed under 
the treaty defined in section 351(a) shall have the effects for purposes of this subsection of an 
application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 



Claims 1,2, 11, 12, and 17 are rejected under 35 U.S.C. 102(e) as being 
anticipated by Feit et al. (US Pub. No. 2001/0056354), hereafter referred to as 
Feit. 



In referencing to claim 1, Feit discloses a distributed information 
processing system (fig. 1), comprising: 

■ a client device interface (fig. 2, #35, user interface form/HTML Form) 
adapted to receive requests for information from a plurality of remote 
devices (fig. 1, #12, Client Systems) (page 6, paragraph 52, lines 1-6, 
11-14); 
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■ a module manager (fig. 1, #14, Server) adapted to receive and route 
said requests from said client device interface (page 6, paragraph 52, 
lines 14-16); and 

■ a plurality of information modules (fig. 1 , #18, Service Providers), 
wherein said information modules register ("identify & communicate", 
page 5, paragraph 50, lines 1-6) with said module manager and 
module manager routes said request to an appropriate one of said 
plurality of information modules in accordance with a type of 
information requested (page 6, paragraph 52, lines 25-38) 

In referencing to claim 2, Feit discloses (page 9, paragraph 179): 

■ the requests to the client device interface are formatted as an plain- 
text formatted email ( 

In referencing to claim 1 1 , Feit discloses a distributed information 
processing system (see fig. 1) comprising a subscription service that maintains a 
subscriber database (#16, Proprietary Database), wherein: 

■ information is sent by said information modules (service providers); 
and said subscription database is consulted to determine to which 



Application/Control Number: 10/020,646 Page 6 

Art Unit: 2153 

clients (client privileges) the information should be forwarded (page 
4, paragraph 42, lines 1-10) 

In referencing to claims 12 and 17, Feit discloses a method of (fig. 4) and 
a computer readable medium containing computer executable instructions for 
(page 2, paragraph 18, lines 1-5) receiving and responding to requests in a 
distributed information processing system, the method comprising: / the 
computer executable instructions for performing the steps of: 

■ receiving a request at a client interface (user interface form/HTML 
form) (page 6, paragraph 52, lines 1-6, 1 1-14); 

■ forwarding said request to a module manager (server system) 
(page 6, paragraph 52, lines 14-16, 25-29), 

■ consulting (obtaining qualification requirements) a registry of 
available information modules (service providers) (page 5, 
paragraph 50, lines 1-13); 

■ forwarding said request to an appropriate information module 
(service provider) as determined in accordance with a type of 
information requested (page 6, paragraph 52, lines 34-38) 
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Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for 
all obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 102 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to which 
said subject matter pertains. Patentability shall not be negatived by the manner in which the 
invention was made. 

Claims 3, 5, 6, 15, 16, 20, and 21 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Feit in view of Rubert. et al. (US Patent 6,366,915), 
hereafter referred to as Rubert. 

In referencing to claim 3, Feit teaches all the limitations of claim 1 as set 
forth above. Although, Feit teachers all of these features, Feit does not explicitly 
disclose that a response generated at the information module (service provider) 
is returned to the requestor (client) by the client device interface (user interface 
form/HTML form) via the module manager (server). Nonetheless, this feature 
would have been an obvious modification to the system disclosed by Feit as 
evidenced by Rubert. 

In analogous art, Rubert discloses a distributed information processing 
system (see fig. 3), comprising a client device interface (#365, IR System 
Interface) adapted to receive requests for information from a plurality of remote 
devices (#360-#380, client computer systems); a module manager (#300, 
Information Reporter (IR) System) adapted to receive and route said requests 
(#392) from said client device interface; and a plurality of information modules 
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(#350-#354, database (DB) servers), and module manager routes said request 
(#396) to an appropriate one of said plurality of information modules in 
accordance with a type of information requested (col. 3, line 1 - col. 4, line 7). 
Rubert further discloses: 

■ the appropriate one of said plurality of information modules (DB 
servers) generates a response (fig. 3, #396) that is returned to said 
[Query Executer (QE) of the] module manager (IR System) (10, 
lines 20-27); and 

■ said [QE of the] module manager (IR System) routes said response 
(fig. 3. #392) to said client interface device (IR System Interface) for 
delivery to a requestor (col. 11, lines 13-16, col. 9, lines 17-19) 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert where Feit's system would return the information generated at 
the information module to the module manager, where it could then be delivered 
to the requestor via the client device interface. 

The motivation for doing so would be to allow for bi-directional interactions 
with the requestor (ex. prompt for additional service, advertisements) (see Feit, 
page 2, paragraph 16-17). 
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In referencing to claims 5, 15, and 20, Feit teaches all the limitations of 
claims 1,12, and 17 as set forth above. Feit does not explicitly disclose that the 
requests are made to the module manager as one of a synchronous or 
asynchronous request. Nonetheless, this feature would have been an obvious 
modification to the system disclosed by Feit as evidenced by Rubert. In 
analogous art, Rubert discloses: 

■ requests are made to said module manager (IR System) as one of 
a synchronous or asynchronous request, wherein synchronous 
requests (low impact query) are handled on a first-in-first-out basis, 
and wherein asynchronous requests are processed and returned 
when completed (col. 10, line 61 - col. 11, line 4) 

Given this feature, a person of ordinary skill in the art would have readily 
recognized the advantages and desirability of combing the teachings of Feit and 
Rubert where Feit's system requests could be synchronous or asynchronous. 

The motivation for doing so would be for load balancing purposes to 
minimize the load on the information module by postponing the retrieval of 
requested information (see Rubert, col. 3., lines 23-27) 

In referencing to claims 6 and 21 , Feit teaches all the limitations of claims 
1 and 17 as set forth above. Feit does not explicitly disclose instances of the 
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module manager. Nonetheless, this feature would have been an obvious 
modification to the system disclosed by Feit as evidenced by Rubert. In 
analogous art, Rubert implicitly discloses: 

■ (claims 6 and 21 respectively) instances (session logon to DB 
server) of said [QE of the] module manager (IR system) are created 
each time a new request is received / creating an instance (session 
logon to DB server) of said [QE of the] module manager upon 
receiving said request (col., 10, lines 20-27); and 

■ (claims 6 and 21 respectively) discarded after the request has been 
handled / discarding said instance (inherent session logoff) after 
said response has been handled (col., 10, lines 20-27) 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert where Feit's where instances of the module manager are created 
and discarded per request. 

The motivation for doing so would be to avoid the chances of unauthorized 
access to the information modules by discarding the module instance (see 
Rubert, col. 4, lines 25-29). 
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In referencing to claim 16, Feit teaches all the limitations of claim 12 as set 
forth above. Feit does not explicitly disclose a response generated at the 
information module (service provider). Nonetheless, this feature would have 
been an obvious modification to the system disclosed by Feit as evidenced by 
Ruber! In analogous art, Rupert discloses: 

■ generating (executing) information in the form of a response (fig. 3, 
#396) at one of said information modules (DB server) (col. 10, lines 
20-27); 

Feit further discloses (page 4, paragraph 42, lines 1-10): 

■ consulting said subscriber database (fig. 1, #16, Proprietary 
Database); and 

Feit does not explicitly disclose a response generated at the information 
module (service provider) is forwarded to clients. Nonetheless, this feature 
would have been an obvious modification to the system disclosed by Feit as 
evidenced by Rubert. In analogous art, Rupert discloses: 

■ forwarding said response (fig. 3, #392) to clients (col. 1 1 , lines 13- 
16, col. 9, lines 16-18) 
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As set forth above in reference to claim 6, Rubert implicitly teaches (col., 
10, lines 20-27): 

■ creating an instance (session logon to DB server ) of said [QE of 
the] module manager upon receiving said request; and 

■ discarding said instance (inherent session logoff) after said 
response has been handled 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert where Feit's responses to requests could be generated at the 
information module (server) and forwarded to the clients in accordance with the 
subscriber database (proprietary database). Accordingly, instances of the 
module manager could be created and discarded per each request. 

The motivation as set forth above in reference to claims 3 and 6 would be 
to allow for bi-directional communication and avoid unauthorized access to the 
information modules. 

Claim 7 is rejected under 35 U.S.C. 103(a) as being unpatentable over 
Feit in view of Rubert and in further view of Hunt (US Publication 2002/0087657). 
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Feit in view of Rubert teach all the limitations of claims 1 and 6 as set forth 
above. Feit in view of Rubert do not explicitly teach stateless and multithreaded 
module manager instances (sessions). Nonetheless, this feature would have 
been an obvious modification to the system disclosed by Feit and Rubert as 
evidenced by Hunt. 

In analogous art, Hunt discloses a distributed information processing system 
(see fig. 4), comprising a client device interface (#442, Application Program 
Interface (API)) adapted to receive requests for information from a plurality of 
remote devices #402, Client Devices); a module manager (#404, Server) 
adapted to receive said requests (# 450) from said client device interface (page 
3, paragraph 40). Hunt further discloses: 

■ instances (sessions) of said module manager (server) are stateless 
(page 3, paragraph 42-43, line 9) and multi-threaded (page 4, 
paragraph 50) 

[the module manger (server) does not save the state (SONE) of the 
connection and is therefore stateless] 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert in view of Hunt where Rubert's instances of module manager are 
stateless and multi-threaded. 
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The motivation for doing so would be so that once the request is serviced 
and the session/connection is terminated, the module manger would be 
burdened by maintaining the state information on behalf of the client (see Hunt, 
page 2, paragraph 17). In addition, the multi-threaded would allow other 
requests to be processed concurrently. 



Claims 8, 9, and 10 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Feit in view of Strahm et al. (US Pub. No. 2003/0046337), 
hereafter referred to as Strahm, in further view of Langseth et al. (US Patent 
6,741 ,980), hereafter referred to as Langseth. 

In referencing to claims 8 and 9 Feit teaches all the limitations of claim 1 
as set forth above. Feit discloses a remote information module (fig. 1, #18, 
service provider), but does not explicitly disclose a local information module 
loaded via inter-process communication. Furthermore, Feit is silent as to how his 
remote information module is loaded. Nonetheless, these features would have 
been obvious modifications to the system disclosed by Feit as evidenced by 
Strahm and Langseth. 

In analogous art, Strahm discloses a distributed information processing 
system (see fig. 2) with computer readable medium containing computer 
executable instructions (page 5, paragraph 67, lines 1-11) comprising a client 
device interface (fig. 2, #222, Network Interface) adapted to receive requests for 
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information from a plurality of remote devices (fig. 2, #214(x), Clients); a module 
manager (fig. 2, #204, Web Server) adapted to receive and route said requests 
from said client device interface; and a plurality of [local] information modules 
(fig. 2, #210 & #212, Storage), and module manager routes said request to an 
appropriate one of said plurality of [local] information modules in accordance with 
a type of information requested (page 1, paragraph 12, lines 1-5, paragraph 17, 
lines 1-6). Strahm further discloses: 

■ (claim 8) information modules (storage) are loaded locally (via fig. 
2, #208, Web Content Monitor & Loader), wherein local modules 
reside on a same physical device as said module manager (page 4, 
paragraph 53-54) 



Strahm further discloses: 

■ (claim 9) communication (query) between locally loaded modules 
(storage) and said module manager (web server) is accomplished 
via inter-process communication (page 1, paragraph 17) * 

In analogous art, Langseth discloses a distributed information processing 
system (see fig. 2B), comprising a client device interface (#24, Web Subscription 
Interface) adapted to receive requests for information from a plurality of remote 
devices (#22, End Users); a module manager (#26, Subscriber Database 
System) adapted to receive and route said requests from said client device 
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interface; and a plurality of information modules (#40 Channel Databases), and 
module manager retrieves said request from an appropriate one of said plurality 
of information modules in accordance with a type of information requested (col. 
1 1 , lines 21-29, 32-36). Langseth further discloses: 

■ (claim 8) information modules (channel databases) are loaded 
remotely (via fig. 2B, #28, Data Load System), wherein remote 
modules (channel databases) are located on other devices (col. 11, 
lines 34-36) 

Given all of these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit in view of Strahm and Langseth where Feit's system could also include local 
information modules that are loaded locally via inter-process communication 
(Strahm). Furthermore, the already existing remote information modules could 
be loaded remotely (Langseth). 

The motivation for doing so would be so that the loading of information 
modules in general would allow the most current information to be maintained via 
periodic feeds (see Langseth, col. 4., lines 16-21). Furthermore, selected 
information modules could be loaded locally to store information that is most 
frequently requested, thus reducing or eliminating the load on the network and 
allowing for a quicker turn around time (see Strahm page 3, paragraph 44, lines 
4-8). 



Application/Control Number: 10/020,646 



Art Unit: 2153 



Page 



In referencing to claim 10, Feit implicitly discloses (page 7, paragraph 55): 

■ communication (formatted request) between remotely loaded 
modules (service providers) and said module manager (server) is 
accomplished via TCP/IP sockets ("common data format protocol") 



Claims 13, 18, 22, 23, 24, 30, and 31 are rejected under 35 U.S.C. 103(a) 
as being unpatentable over Feit in view of Rubert in further view of Strahm. 

In referencing to claims 13 and 18, Feit teaches all the limitations of claims 
12 and 17 as set forth above. Feit further discloses method/step of: 

■ (claims 13 & 18) maintaining a list of supported services provided 
by each of said information modules (service providers) (page 6, 
paragraph 54, lines 1-6) 

Although Feit teaches this feature, Feit does not explicitly disclose that a 
response processed at the information module (service provider) is returned to 
the requestor (client) by the client device interface (user interface form/HTML 
form) via the module manager (server). Nonetheless, this feature would have 
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been an obvious modification to the system disclosed by Feit as evidenced by 
Rubert. Rupert discloses a method/step of: 

■ (claim 13 only) processing (executing) the request at said 
appropriate information module (DB server) (col. 10, lines 20-27); 

■ (claim 13 only) generating a response (fig. 3, # 396) that is returned 
to said [QE of the] module manager (IR System) (col. 10, lines 20- 
27); and 

■ (claim 13 only) routing said response (fig. 3, #392) to said client 
interface device (IR System Interface) for delivery to a requestor 
(col. 11, lines 13-16, col. 9, lines 16-18) 

Although Feit in view of Rubert teach all of these features, they do not 
explicitly disclose service collisions of plural information modules. Nonetheless, 
this feature would have been an obvious modification to the system disclosed by 
Feit in view of Rubert as evidenced by Strahm. In analogous art, Strahm 
discloses: 

■ (claims 1 3 & 18) handling service collisions if plural information 
modules (storage) are capable of responding to said type of 
information such that only one information module (storage) 
processes said request (page 4, paragraph 53-54) 
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[the monitor updates one information module (#212 storage) with 
the information (web content) of another information module 
(storage #210), therefore both information modules would at one 
point contain the same type of information thus being capable of 
responding to the request, but only one information module 
(storage #212) responds to the request] 

Given all of these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert in view of Strahm where in addition to maintaining a list of 
supported services of the information modules, Feit's system could return the 
information generated at the information module to the module manager, where it 
could then be delivered to the requestor via the client device interface. Feit's 
system could also allow only one of the information modules to reply to a request 
during a service collision. 

The motivation as set forth above in reference to claim 3, would be to 
allow bi-directional communication to the requestor. Additionally, the load on the 
information modules could be reduced in the case of service collisions because 
only one information module would respond to a request for the same type of 
information, eliminating unnecessary processing of requests (see Rubert, col. 2, 
lines 26-37). 
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In referencing to claim 22, Feit discloses a module manager (fig. 1, #14, 
Server) that manages a request for information received at a mailbox (at an 
inherent email inbox, page 9,paragraph 179), comprising: 

■ a registry (qualification requirements) of information modules 
(service providers) (page 5, paragraph 50, lines 1-13); 

Although, Feit teaches this feature, Feit does not explicitly disclose a 
module loading function. Nonetheless, this feature would have been an obvious 
modification to the system disclosed by Feit as evidenced by Strahm. In 
analogous art, Strahm discloses: 

■ a module loading function (fig. 2. # 208, Web Content Monitor 
and Page Loader) for dynamically loading said information 
modules (fig. 3, # 212, Storage) upon receipt of said request 
(event) (page 4, paragraph 53-54) 

Feit further discloses: 

■ said module manager (fig. 2, # 14, Server) routes said request 
to an appropriate information module (fig. 2, #18, Service 
Provider) for resolution (page 6, paragraph 52, lines 34-38) 
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Although, Feit teaches this feature, Feit does explicitly disclose a 
response returned to the module manager (server) once the request is resolved 
at the appropriate information module (sen/ice provider). Nonetheless, this 
feature would have been an obvious modification to the system disclosed by Feit 
as evidenced by Rubert. Rubert discloses: 

■ said appropriate information module (DB sever) resolves said 
request and returns a response (fig. 3, #292) to said [QE of the] 
module manager (IR System) (col. 10, lines 20-27) 

Given all of these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Fiet and Rubert in view of Strahm where the Feit's information module could be 
loaded upon receipt of the request and a response returned to the module 
manager. 

The motivation for doing so would be so that the requested content would 
be dynamically loaded per request so as to update the information module since 
the last request (see Strahm, page 4, paragraph 54). Additionally, the response 
could be returned to the module manger, acting on behalf of the requestor. 



In referencing to claim 23, Feit discloses (page 6, paragraph 54, lines 1-6): 
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■ said module manager (server) maintains a list of supported 
services provided by each of said information modules (service 
providers) 



In referencing to claim 24, Feit teaches (page 5, paragraph 50, lines 1-13) 
the registering of information modules (service providers) as set forth above in 
reference to claim 22. Strahm teaches the handling of service collisions (page 4, 
paragraph 53-54) as set forth above in reference to claim 13. 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert in view of Strahm where Feit's module managers could handle 
service collisions such that if plural information modules register as supporting a 
same service, the module manager could determine which information module 
would handle the request 

The motivation as set forth above in reference to claims 13, would be to 
avoid the unnecessary processing of requests. 



In referencing to claim 30, Feit and Rubert in view of Strahm teach all the 
limitations of claim 22 as set forth above. Feit in does not explicitly disclose 
instances of a module manager. Nonetheless, this feature would have been an 
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obvious modification to the system disclosed by Feit as evidenced by Rubert. In 
analogous art, Rubert implicitly discloses (col., 10, lines 20-27): 

■ instances (logon session to DB server) of said [QE of the] 
module manager are created each time a new request is 
received and discarded (inherent session logoff) after the 
request has been handled 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert in view of Strahm where Feit's instances of the module manager 
are created and discarded per request. 

The motivation as set forth above in reference to claim 6, would be to 
avoid unauthorized access to the information module. 

s 

In referencing to claim 31, Feit discloses a user interface (user interface 
form/HTML form), wherein: 

■ said user interface is adapted to configure said module manager 
(page 6, paragraph 52, lines 14-16) 
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Claims 25-27 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Feit in view of Rubert, in view of Strahm in further view of Langseth. 

In referencing to claims 25 and 26, Feit and Rubert in view of Strahm 
teach all the limitations of claim 22 as set forth above. Feit is does not explicitly 
teach a locally loaded information module via inter-process communication. 
Furthermore, Feit is silent as to how his remote information module is loaded. 
Nonetheless, these features would have been obvious modifications to the 
system disclosed by Feit as evidenced by Strahm and Langseth. In analogous 
art Strahm discloses: 

■ (claim 25) local module loading functions (fig. 2, #208, Web 
Content Monitor & Loader), wherein said local loading function 
loads information modules (storage) that reside on a same physical 
device as said module manager (page 4, paragraph 53-54) 

Strahm further discloses: 

■ (claim 26) local modules (storage) communicate (query) with said 
module manager (Web Server) via one of inter-process 
communication (query, page 1, paragraph 17) 



In analogous art, Langseth discloses: 
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■ (claim 25) remote module loading functions (via fig. 2B, #28, Data 
Load System), wherein said remote loading function load 
information modules (channel databases) that reside on devices 
logically connected to said module manager (col. 11, lines 34-36) 



Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Rubert in view of Strahm and Langseth were Feit's information modules 
(service providers) could be loaded locally via inter-process communication 
(Strahm) and remotely (Langseth). 

The motivation as set forth above in reference to claims 8 and 9, would be 
to reduce the load on the network and allow for a quicker response time. 

In referencing to claim 27, Feit discloses (page 7, paragraph 55): 

■ remote modules communicate with said module manager via 
TCP/IP sockets ("common data format protocol") 
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Claims 4, 14, and 19 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Feit in view of Hunt, and in further view of Bavadekar (US 
Publication 2003/0009571). 

Feit teaches all the limitations of claims 1,12, and 17 as set forth above. 
Although Feit teaches all of these features, Feit does not explicitly disclose that 
requests and responses formatted as serializable Java objects. Nonetheless, 
this feature would have been an obvious modification to the system disclosed by 
Feit as evidenced by Hunt in view of Bavadekar. 

In analogous art, Hunt discloses an Application Protocol Interface (API) 
client interface (fig. 4, #442) that accepts requests from clients and provides 
responses from the module manager. Hunt neither discloses that the requests 
and response are formatted as serializable java object. Nonetheless this feature 
would have been an obvious modification to the system disclosed by Hunt as 
evidenced by Bavadekar. 

In analogous art, Bavadekar discloses a distributed information processing 
system (see fig. 1), comprising a client device interface (page 1, paragraph 4, 
lines 15-17) adapted to receive requests (messages), for information from a 
plurality of remote devices (#102A-102C); a module manager (#100A, Messaging 
Server) adapted to receive (fig. 6B, step 624) and route (fig. 6B, step 626) said 
requests from said client device interface; and a plurality of information modules 
(#104A-104B, Servers), and module manager routes said request to an 
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appropriate one of said plurality of information modules in accordance with a type 
of information requested. Bavadekar further discloses: 

■ requests and responses (entered via the API) are formatted as 
Java objects (page 5, paragraph 73, page 1, paragraph 9 & 14) 

Given these features, a person of ordinary skill in the art would have 
readily recognized the advantages and desirability of combing the teachings of 
Feit and Hunt in view of Bavadekar where request and responses are formatted 
as serializable Java objects. 

The motivation for doing so would be so that the state of the object could 
be saved and sent across the network connection between the requestor and 
module manager. 

Claims 28 and 29 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Feit, Rubert, and Strahm in further view of Hunt and 
Bavadekar. 

In referencing to claim 28, Feit is view of Rubert and Strahm teach all the 
limitations of claim 22 as set forth above. Feit is view of Rubert and Strahm do 
not explicitly disclose requests made of serializable Java objects. Nonetheless, 
this feature would have been an obvious modification to the system discloses by 



Application/Control Number: 10/020,646 Page 
Art Unit: 2153 

Feit, Rubert, and Strahm as evidenced by Hunt in view of Bavadekar. In 
analogous art, Bavadekar discloses: 

■ request (entered via the API) is made of a serializable Java 
object (page 5, paragraph 73, page 1, paragraph 9 & 14) 

Given this feature, a person of ordinary skill in the art would have readily 
recognized the advantages and desirability of combing the teachings of Feit and 
Rubert and Strahm in view of Hunt and Bavadekar where requests are made of 
serializable Java objects. 

The motivation as set forth above in reference to claim 4, would be so that 
the state of the object could be saved and sent across the network connection 
between the requestor and module manager. 

In referencing to claim 29, Feit and Rubert in view of Strahm teach all the 
limitations of claim 22 as set forth above. Feit does not explicitly disclose that the 
requests are made to the module manager as one of a synchronous or 
asynchronous request. Nonetheless, this feature would have been an obvious 
modification to the system disclosed by Feit as evidenced by Rubert. In 
analogous art, Rubert discloses: 

■ said request is either synchronous or asynchronous, wherein a 
synchronous request is handled on a first-in-first-out basis, and 
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wherein an asynchronous request is processed and a response 
returned in accordance with a processing time of the request 
(col. 10, line 61 - col. 11, line 4) 

Given this feature, a person of ordinary skill in the art would have readily 
recognized the advantages and desirability of combing the teachings of Feit and 
Rubert in view of Strahm and Langseth where Feit's requests could be 
synchronous or asynchronous. 

The motivation as set forth above in reference to claim 5, would be for 
load balancing purposes. 



Conclusion 

Any inquiry concerning this communication or earlier communications from 
the examiner should be directed to Avalon Blenman whose telephone number is 
(571) 272-5864. The examiner can normally be reached on Mon-Fri, 7:00 AM - 
4:30 PM (even date Mons. off). 

If attempts to reach the examiner by telephone are unsuccessful, the 
examiner's supervisor, Glenton Burgess can be reached on (571) 272-3949. The 
fax phone number for the organization where this application or proceeding is 
assigned is 703-872-9306. 
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